@Tearran IMHO it would be PITA to maintain two copies of armbian-config.

What about using an env var (eg, ARMBIAN_CONFIG_DEBUG or just DEBUG) to show the timing info? Eg,

DEBUG=1 ./bin/armbian-config ...

Then in message_checkpoint.sh you can add something like this at the end:

# disable set_checkpoint if DEBUG has not been defined
[[ -n "$DEBUG" ]] || eval "set_checkpoint(){ :; }"

IMHO it would be PITA to maintain two copies

Yes, I would also propose to have one.

What about using an env var (eg, ARMBIAN_CONFIG_DEBUG or just DEBUG) to show the timing info?

@dimitry-ishenko I am not opposed to using a DEBUG environment variable in general. However, I would like to clarify that the messages displayed are not meant for debugging purposes and are not being introduced with this PR. These messages were previously implemented to improve the user experience by indicating that the application is working and not frozen.

In other words, this PR does not address bugs. Rather, it outlines the expected parsing load time limitations due to the linear nature of bash, such as function variable racing and other inherent constraints.

The addition of the timestamp is multifaceted. Firstly, IMHO it is important to recognize the limitations of bash, so that expected limitations are not identified as bugs. Showing loading time addresses this by clearly showing expected behavior. For example, 4 seconds may be undesirable but it is not a bug. By providing these user-facing messages, we aim to enhance user experience by transparently communicating the application's activity, thus avoiding any misconceptions of the application being unresponsive.

@dimitry-ishenko I am not opposed to using a DEBUG environment variable in general. However, I would like to clarify that the messages displayed are not meant for debugging purposes and are not being introduced with this PR. These messages were previously implemented to improve the user experience by indicating that the application is working and not frozen.

@Tearran sorry, not sure why I got the idea this was for debugging. Thanks for the clear explanation, it makes sense.

Sorry, not sure why I got the idea this was for debugging.

no need to apologize, Debugging is a reasonable conclusion; the armbian-config-dev option does resemble debugging. and set_checkpoint option show is intended to serve a debugging purpose , That being said the Discussion of Debugging is valid while it is mindfully relative and IMO is applicable here

Added alias/helper checkpoint with a debug option.
Use in file: checkpoint debug "Starting --api options"
For more, see checkpoint help (set_checkpoint help debug appended).
sudo ./bin/armbian-config --api checkpoint help

Usage: set_checkpoint <start|stop|mark|show> [description] [show]
Commands:
  start              Start the timer.
  stop               Stop the timer.
  mark [description] [time] Mark a checkpoint with an optional description and an optional flag to show the output.
  show               Show the total elapsed time and checkpoints.
  debug              DEBUG checkpoint message

Debug level 2 shows like UX mode, printing each step.

Other DEBUG levels (DEBUG=1, DEBUG=anything) default to set_checkpoint show.

This section doe not print with other DEBUG values
sudo DEBUG=2 ./bin/armbian-config --api checkpoint help

Initializing script                     0 seconds
Loaded Runtime variables...             4 seconds
The current Armbian 24.8.4 stable (bookworm) is supported.           0 seconds
Loaded Dialog...                        0 seconds
Loaded Docs...                          0 seconds
Loaded System helpers...                1 second
Loaded Network helpers...               0 seconds
Loaded Software helpers...              0 seconds
Loaded Runtime conditions...            5 seconds
DEBUG Messages on                       0 seconds
Starting --api options                  0 seconds

The normal output if any from the command line options.

Following shows if debug has a value [[ -n $DEBUG ]]

Exiting --api                           0 seconds
Total elapsed time            : 10 seconds
Initializing script           : 0 seconds
Loaded Runtime variables...   : 4 seconds
The current Armbian 24.8.4 stable (bookworm) is supported.: 0 seconds
Loaded Dialog...              : 0 seconds
Loaded Docs...                : 0 seconds
Loaded System helpers...      : 1 second
Loaded Network helpers...     : 0 seconds
Loaded Software helpers...    : 0 seconds
Loaded Runtime conditions...  : 5 seconds
DEBUG Messages on             : 0 seconds
Starting --api options        : 0 seconds
Exiting --api                 : 0 seconds

@Tearran the problem is not with the testcase, but something else:

Run export TERM=linux
All scripts have been combined and placed into tools/../lib/armbian-config
Processing JSON files, please wait...
JSON files rejoined into 'tools/../lib/armbian-config/config.jobs.json'.
Markdown files created in 'docs' directory, organized by top-level folders for both technical and user documentation.
 ____  _   _ _   _   _____ _____ ____ _____    ____    _    ____  _____ 
|  _ \| | | | \ | | |_   _| ____/ ___|_   _|  / ___|  / \  / ___|| ____|
| |_) | | | |  \| |   | | |  _| \___ \ | |   | |     / _ \ \___ \|  _|  
|  _ <| |_| | |\  |   | | | |___ ___) || |   | |___ / ___ \ ___) | |___ 
|_| \_\\___/|_| \_|   |_| |_____|____/ |_|    \____/_/   \_\____/|_____|
                                                                        
docker: Error response from daemon: Conflict. The container name "/portainer" is already in use by container "c1217285613f07ce14c18731c0856c38778d8964d7ea1141b9a0574bd9b25f3a". You have to remove (or rename) that container to be able to reuse that name.
See 'docker run --help'.
Error: Process completed with exit code 1.

but something else:

yeah, ignore that. Will fix when possible

@Tearran just wanted to say, I like where you are going with that 😃

Link to Youtube, showing DEBUG and loading messages

Off-topic, but wow, it takes 5 seconds to load runtime vars...

This is about all i got for this pr, Unless there are other suggestion I am happy to receive, I believe this is ready to meagre. :)

Off-topic, but wow, it takes 5 seconds to load runtime vars...

IMO Related-topic. Also related is, ./tools/armbian-config-dev, ./tools/config-assemble, and

just wanted to say, I like where you are going with that 😃

Thanks for saying.

or more precisely, parsing in general, are all related to taking steps to sort and be clear this is expected albe it undesirable behavior, as well as some other minor compounding issues that are clearly becoming major. This thing got huge :)

I've been exploring this idea ConfigNG. Unifying the paring data to one source type so we can to output the others. in part to remove the need of the current runtme.sh jq updates